การตรวจสอบความถูกต้องของ React Server Action: คู่มือฉบับสมบูรณ์สำหรับการประมวลผลอินพุตฟอร์มและความปลอดภัย

การมาถึงของ React Server Actions ถือเป็นการเปลี่ยนแปลงกระบวนทัศน์ที่สำคัญในการพัฒนาแบบ full-stack ด้วยเฟรมเวิร์กอย่าง Next.js ด้วยการอนุญาตให้คอมโพเนนต์ฝั่งไคลเอนต์เรียกใช้ฟังก์ชันฝั่งเซิร์ฟเวอร์ได้โดยตรง ตอนนี้เราสามารถสร้างแอปพลิเคชันที่สอดคล้อง มีประสิทธิภาพ และโต้ตอบได้มากขึ้นโดยใช้โค้ด boilerplate น้อยลง อย่างไรก็ตาม abstraction ใหม่ที่ทรงพลังนี้ก็นำมาซึ่งความรับผิดชอบที่สำคัญยิ่ง นั่นคือ: การตรวจสอบความถูกต้องของอินพุตและความปลอดภัยที่แข็งแกร่ง

เมื่อขอบเขตระหว่างไคลเอนต์และเซิร์ฟเวอร์กลายเป็นสิ่งที่ไร้รอยต่อเช่นนี้ มันง่ายที่จะมองข้ามหลักการพื้นฐานของความปลอดภัยบนเว็บ อินพุตใดๆ ที่มาจากผู้ใช้ถือว่าไม่น่าเชื่อถือและต้องได้รับการตรวจสอบอย่างเข้มงวดบนเซิร์ฟเวอร์ คู่มือนี้จะให้การสำรวจที่ครอบคลุมเกี่ยวกับการประมวลผลและการตรวจสอบความถูกต้องของอินพุตฟอร์มภายใน React Server Actions ซึ่งครอบคลุมทุกอย่างตั้งแต่หลักการพื้นฐานไปจนถึงรูปแบบขั้นสูงที่พร้อมใช้งานจริง เพื่อให้แน่ใจว่าแอปพลิเคชันของคุณเป็นมิตรต่อผู้ใช้และปลอดภัย

React Server Actions คืออะไรกันแน่?

ก่อนที่จะเจาะลึกเรื่องการตรวจสอบความถูกต้อง เรามาทบทวนสั้นๆ กันก่อนว่า Server Actions คืออะไร โดยพื้นฐานแล้ว มันคือฟังก์ชันที่คุณกำหนดบนเซิร์ฟเวอร์ แต่สามารถเรียกใช้งานจากฝั่งไคลเอนต์ได้ เมื่อผู้ใช้ส่งฟอร์มหรือคลิกปุ่ม Server Action สามารถถูกเรียกได้โดยตรง โดยไม่จำเป็นต้องสร้าง API endpoints ด้วยตนเอง, จัดการคำขอ `fetch`, และจัดการสถานะ loading/error

พวกมันถูกสร้างขึ้นบนพื้นฐานของฟอร์ม HTML และ `FormData` API ของ Web Platform ทำให้มันได้รับการปรับปรุงแบบก้าวหน้า (progressively enhanced) เป็นค่าเริ่มต้น ซึ่งหมายความว่าฟอร์มของคุณจะยังคงทำงานได้แม้ว่า JavaScript จะโหลดไม่สำเร็จก็ตาม ซึ่งมอบประสบการณ์การใช้งานที่ยืดหยุ่น

ตัวอย่าง Server Action พื้นฐาน:

            // app/actions.js
'use server';

export async function createUser(formData) {
  const name = formData.get('name');
  const email = formData.get('email');

  // ... logic to save user to the database
  console.log('Creating user:', { name, email });
}

// app/page.js
import { createUser } from './actions';

export default function UserForm() {
  return (
    

      
      
      Create User
    
  );
}
            

              
                Copy
              
            
          

ความเรียบง่ายนี้ทรงพลัง แต่ก็ซ่อนความซับซ้อนของสิ่งที่เกิดขึ้นอยู่เบื้องหลัง ฟังก์ชัน `createUser` ทำงานบนเซิร์ฟเวอร์เท่านั้น แต่กลับถูกเรียกจากคอมโพเนนต์ฝั่งไคลเอนต์ การเชื่อมต่อโดยตรงไปยังตรรกะของเซิร์ฟเวอร์ของคุณนี่เองคือเหตุผลว่าทำไมการตรวจสอบความถูกต้องจึงไม่ใช่แค่ฟีเจอร์ แต่เป็นข้อบังคับ

ความสำคัญที่ไม่เคยเปลี่ยนแปลงของการตรวจสอบความถูกต้อง

ในโลกของ Server Actions ทุกฟังก์ชันเปรียบเสมือนประตูที่เปิดสู่เซิร์ฟเวอร์ของคุณ การตรวจสอบที่เหมาะสมทำหน้าที่เป็นยามที่เฝ้าประตูนั้น และนี่คือเหตุผลว่าทำไมจึงเป็นสิ่งที่ขาดไม่ได้:

• ความสมบูรณ์ของข้อมูล (Data Integrity): ฐานข้อมูลและสถานะของแอปพลิเคชันของคุณขึ้นอยู่กับข้อมูลที่สะอาดและคาดเดาได้ การตรวจสอบความถูกต้องช่วยให้แน่ใจว่าคุณจะไม่จัดเก็บที่อยู่อีเมลที่ผิดรูปแบบ, สตริงว่างเปล่าในช่องที่ควรเป็นชื่อ, หรือข้อความในช่องที่ควรเป็นตัวเลข
• ประสบการณ์ผู้ใช้ที่ดีขึ้น (UX): ผู้ใช้ทำผิดพลาดได้ ข้อความแสดงข้อผิดพลาดที่ชัดเจน, ทันที, และตรงประเด็นจะช่วยแนะนำให้พวกเขาแก้ไขข้อมูลที่ป้อน, ลดความหงุดหงิด และเพิ่มอัตราการกรอกฟอร์มจนสำเร็จ
• ความปลอดภัยที่แข็งแกร่ง (Ironclad Security): นี่เป็นส่วนที่สำคัญที่สุด หากไม่มีการตรวจสอบฝั่งเซิร์ฟเวอร์ แอปพลิเคชันของคุณจะเสี่ยงต่อการโจมตีหลายรูปแบบ รวมถึง:
  • SQL Injection: ผู้ไม่หวังดีอาจส่งคำสั่ง SQL ในช่องฟอร์มเพื่อจัดการฐานข้อมูลของคุณ
  • Cross-Site Scripting (XSS): หากคุณจัดเก็บและแสดงผลอินพุตของผู้ใช้ที่ไม่ผ่านการกรอง (sanitized) ผู้โจมตีอาจแทรกสคริปต์ที่เป็นอันตรายซึ่งจะทำงานในเบราว์เซอร์ของผู้ใช้คนอื่น
  • Denial of Service (DoS): การส่งข้อมูลที่มีขนาดใหญ่เกินคาดหรือต้องใช้การคำนวณสูงอาจทำให้ทรัพยากรเซิร์ฟเวอร์ของคุณทำงานหนักเกินไป

การตรวจสอบฝั่งไคลเอนต์ vs. ฝั่งเซิร์ฟเวอร์: พันธมิตรที่จำเป็น

สิ่งสำคัญคือต้องเข้าใจว่าการตรวจสอบความถูกต้องควรเกิดขึ้นในสองที่:

1. การตรวจสอบฝั่งไคลเอนต์ (Client-Side Validation): นี่คือเพื่อ UX มันให้ผลตอบรับทันทีโดยไม่ต้องเดินทางไปกลับผ่านเครือข่าย คุณสามารถใช้แอตทริบิวต์ HTML5 ง่ายๆ เช่น `required`, `minLength`, `pattern`, หรือ JavaScript เพื่อตรวจสอบรูปแบบขณะที่ผู้ใช้พิมพ์ อย่างไรก็ตาม มันสามารถถูกข้ามไปได้อย่างง่ายดายโดยการปิดใช้งาน JavaScript หรือใช้เครื่องมือสำหรับนักพัฒนา
2. การตรวจสอบฝั่งเซิร์ฟเวอร์ (Server-Side Validation): นี่คือเพื่อความปลอดภัยและความสมบูรณ์ของข้อมูล มันเป็นแหล่งความจริงสูงสุดของแอปพลิเคชันของคุณ ไม่ว่าจะเกิดอะไรขึ้นบนไคลเอนต์ เซิร์ฟเวอร์ต้องตรวจสอบทุกอย่างที่ได้รับอีกครั้ง Server Actions เป็นสถานที่ที่สมบูรณ์แบบในการนำตรรกะนี้ไปใช้

กฎง่ายๆ: ใช้การตรวจสอบฝั่งไคลเอนต์เพื่อประสบการณ์ผู้ใช้ที่ดีขึ้น แต่เชื่อถือเฉพาะการตรวจสอบฝั่งเซิร์ฟเวอร์เพื่อความปลอดภัยเสมอ

การนำการตรวจสอบความถูกต้องไปใช้ใน Server Actions: จากพื้นฐานสู่ขั้นสูง

เรามาสร้างกลยุทธ์การตรวจสอบความถูกต้องของเรากัน โดยเริ่มจากวิธีง่ายๆ และก้าวไปสู่โซลูชันที่แข็งแกร่งและปรับขนาดได้มากขึ้นโดยใช้เครื่องมือที่ทันสมัย

แนวทางที่ 1: การตรวจสอบด้วยตนเองและการคืนค่าสถานะ

วิธีที่ง่ายที่สุดในการจัดการการตรวจสอบความถูกต้องคือการเพิ่มคำสั่ง `if` ภายใน Server Action ของคุณและคืนค่าอ็อบเจกต์ที่บ่งชี้ความสำเร็จหรือความล้มเหลว

            // app/actions.js
'use server';

import { redirect } from 'next/navigation';

export async function createInvoice(formData) {
  const customerName = formData.get('customerName');
  const amount = formData.get('amount');

  if (!customerName || customerName.trim() === '') {
    return { success: false, message: 'Customer name is required.' };
  }

  if (!amount || isNaN(Number(amount)) || Number(amount) <= 0) {
    return { success: false, message: 'Please enter a valid amount greater than zero.' };
  }

  // ... logic to create the invoice in the database
  console.log('Invoice created for', customerName, 'with amount', amount);
  
  redirect('/dashboard/invoices');
}
            

              
                Copy
              
            
          

แนวทางนี้ใช้ได้ แต่มีข้อบกพร่องด้าน UX ที่สำคัญ: มันต้องรีโหลดหน้าเว็บใหม่ทั้งหมดเพื่อแสดงข้อความแสดงข้อผิดพลาด เราไม่สามารถแสดงข้อความบนหน้าฟอร์มได้อย่างง่ายดาย นี่คือจุดที่ hook ของ React สำหรับ Server Actions เข้ามามีบทบาท

แนวทางที่ 2: การใช้ `useFormState` เพื่อการจัดการข้อผิดพลาดที่ราบรื่น

hook `useFormState` ถูกออกแบบมาเพื่อจุดประสงค์นี้โดยเฉพาะ มันช่วยให้ Server Action สามารถคืนค่าสถานะที่สามารถใช้อัปเดต UI ได้โดยไม่ต้องมีการนำทางแบบเต็มหน้า มันเป็นรากฐานของการจัดการฟอร์มสมัยใหม่ด้วย Server Actions

เรามาปรับปรุงฟอร์มสร้างใบแจ้งหนี้ของเรากัน

ขั้นตอนที่ 1: อัปเดต Server Action

ตอนนี้ action จะต้องรับอาร์กิวเมนต์สองตัว: `prevState` และ `formData` มันควรคืนค่าอ็อบเจกต์สถานะใหม่ที่ `useFormState` จะใช้เพื่ออัปเดตคอมโพเนนต์

            // app/actions.js
'use server';

import { revalidatePath } from 'next/cache';
import { redirect } from 'next/navigation';

// Define the initial state shape
const initialState = {
  message: null,
  errors: {},
};

export async function createInvoice(prevState, formData) {
  const customerName = formData.get('customerName');
  const amount = formData.get('amount');
  const status = formData.get('status');

  const errors = {};
  if (!customerName || customerName.trim().length < 2) {
    errors.customerName = 'Customer name must be at least 2 characters.';
  }
  if (!amount || isNaN(Number(amount)) || Number(amount) <= 0) {
    errors.amount = 'Please enter a valid amount.';
  }
  if (status !== 'pending' && status !== 'paid') {
    errors.status = 'Please select a valid status.';
  }

  if (Object.keys(errors).length > 0) {
    return {
      message: 'Failed to create invoice. Please check the fields.',
      errors,
    };
  }

  try {
    // ... logic to save to database
    console.log('Invoice created successfully!');
  } catch (e) {
    return {
      message: 'Database Error: Failed to create invoice.',
      errors: {},
    };
  }

  // Revalidate the cache for the invoices page and redirect
  revalidatePath('/dashboard/invoices');
  redirect('/dashboard/invoices');
}

            

              
                Copy
              
            
          

ขั้นตอนที่ 2: อัปเดตคอมโพเนนต์ฟอร์มด้วย `useFormState`

ในคอมโพเนนต์ฝั่งไคลเอนต์ของเรา เราจะใช้ hook เพื่อจัดการสถานะของฟอร์มและแสดงข้อผิดพลาด

            // app/ui/invoices/create-form.js
'use client';

import { useFormState } from 'react-dom';
import { createInvoice } from '@/app/actions';

const initialState = {
  message: null,
  errors: {},
};

export function CreateInvoiceForm() {
  const [state, dispatch] = useFormState(createInvoice, initialState);

  return (
    

      

        Customer Name
        
        {state.errors?.customerName && 
          
{state.errors.customerName}
}
      
      
      

        Amount
        
        {state.errors?.amount && 
          
{state.errors.amount}
}
      

      {/* ... other fields ... */}

      {state.message && 
{state.message}
}
      
      Create Invoice
    
  );
}
            

              
                Copy
              
            
          

ตอนนี้ เมื่อผู้ใช้ส่งฟอร์มที่ไม่ถูกต้อง Server Action จะทำงาน คืนค่าอ็อบเจกต์ข้อผิดพลาด และ `useFormState` จะอัปเดตตัวแปร `state` คอมโพเนนต์จะ re-render และแสดงข้อความแสดงข้อผิดพลาดเฉพาะสำหรับแต่ละช่องข้างๆ กัน—ทั้งหมดนี้โดยไม่ต้องรีโหลดหน้าเว็บ นี่คือการปรับปรุง UX ครั้งใหญ่!

แนวทางที่ 3: การปรับปรุง UX ด้วย `useFormStatus`

จะเกิดอะไรขึ้นขณะที่ Server Action กำลังทำงาน? ผู้ใช้อาจคลิกปุ่มส่งหลายครั้ง เราสามารถให้ผลตอบรับได้โดยใช้ hook `useFormStatus` ซึ่งให้ข้อมูลเกี่ยวกับสถานะของการส่งฟอร์มครั้งล่าสุด

สำคัญ: `useFormStatus` ต้องใช้ในคอมโพเนนต์ที่เป็นลูกขององค์ประกอบ `

            // app/ui/submit-button.js
'use client';

import { useFormStatus } from 'react-dom';

export function SubmitButton() {
  const { pending } = useFormStatus();

  return (
    
      {pending ? 'Creating...' : 'Create Invoice'}
    
  );
}

// In your CreateInvoiceForm component:
import { SubmitButton } from './submit-button';

// ...

  {/* ... form fields ... */}
  

            

              
                Copy
              
            
          

ด้วยการเพิ่มโค้ดง่ายๆ นี้ ปุ่มส่งจะถูกปิดใช้งานและแสดงข้อความ "Creating..." ในขณะที่เซิร์ฟเวอร์กำลังประมวลผลคำขอ ซึ่งช่วยป้องกันการส่งซ้ำและให้ผลตอบรับที่ชัดเจนแก่ผู้ใช้

แนวทางที่ 4: การตรวจสอบความถูกต้องระดับโปรดักชันด้วย Zod

การตรวจสอบด้วย `if` แบบแมนนวลนั้นใช้ได้สำหรับฟอร์มง่ายๆ แต่สำหรับแอปพลิเคชันที่ซับซ้อน มันจะกลายเป็นโค้ดที่ยืดยาว, เกิดข้อผิดพลาดได้ง่าย, และดูแลรักษายาก นี่คือจุดที่ไลบรารีการตรวจสอบสคีมาอย่าง Zod, Yup, หรือ Valibot เข้ามามีบทบาท

Zod เป็นไลบรารีการประกาศและตรวจสอบสคีมาที่เน้น TypeScript เป็นหลัก มันช่วยให้คุณสามารถกำหนดสคีมาเดียวสำหรับข้อมูลของคุณที่สามารถใช้ได้ทั้งบนเซิร์ฟเวอร์และไคลเอนต์ ทำให้มั่นใจได้ถึงความสอดคล้องและความปลอดภัยของประเภทข้อมูล (type safety)

ขั้นตอนที่ 1: กำหนด Zod Schema

เรามากำหนดสคีมาสำหรับฟอร์มใบแจ้งหนี้ของเรากัน นี่จะกลายเป็นแหล่งความจริงเพียงแหล่งเดียวสำหรับสิ่งที่ถือว่าเป็นใบแจ้งหนี้ที่ถูกต้อง

            // app/lib/schemas.js
import { z } from 'zod';

export const InvoiceSchema = z.object({
  id: z.string(), // We'll have this for updates, but not creation
  customerId: z.string({ invalid_type_error: 'Please select a customer.' }),
  amount: z.coerce
    .number()
    .gt(0, { message: 'Please enter an amount greater than $0.' }),
  status: z.enum(['pending', 'paid'], {
    invalid_type_error: 'Please select an invoice status.',
  }),
  date: z.string(),
});

export const CreateInvoice = InvoiceSchema.omit({ id: true, date: true });
            

              
                Copy
              
            
          

ขั้นตอนที่ 2: ใช้สคีมาใน Server Action ของคุณ

ตอนนี้ เราสามารถแทนที่การตรวจสอบด้วยตนเองทั้งหมดของเราด้วยการเรียกใช้ Zod schema ของเราเพียงครั้งเดียว เมธอด `safeParse` ของ Zod จะคืนค่าเป็นข้อมูลที่ผ่านการตรวจสอบแล้วหรืออ็อบเจกต์ข้อผิดพลาดโดยละเอียด

            // app/actions.js
'use server';

import { z } from 'zod';
import { CreateInvoice } from '@/app/lib/schemas';

export async function createInvoiceWithZod(prevState, formData) {
  // 1. Validate form fields using Zod
  const validatedFields = CreateInvoice.safeParse({
    customerId: formData.get('customerId'),
    amount: formData.get('amount'),
    status: formData.get('status'),
  });

  // 2. If validation fails, return errors early.
  if (!validatedFields.success) {
    return {
      errors: validatedFields.error.flatten().fieldErrors,
      message: 'Missing Fields. Failed to Create Invoice.',
    };
  }

  // 3. Prepare data for insertion into the database
  const { customerId, amount, status } = validatedFields.data;
  const amountInCents = amount * 100;
  const date = new Date().toISOString().split('T')[0];

  // 4. Insert data into the database
  try {
    // await sql`...` your database query here
    console.log('Successfully created invoice with validated data.');
  } catch (error) {
    return {
      message: 'Database Error: Failed to Create Invoice.',
    };
  }

  // 5. Revalidate and redirect
  revalidatePath('/dashboard/invoices');
  redirect('/dashboard/invoices');
}
            

              
                Copy
              
            
          

สังเกตว่ามันสะอาดขึ้นมากแค่ไหน ตรรกะการตรวจสอบเป็นแบบ declarative และรวมอยู่ในไฟล์สคีมาของเรา ความรับผิดชอบของ action ตอนนี้คือการประสานงานการตรวจสอบ, การประมวลผลข้อมูล, และการโต้ตอบกับฐานข้อมูล เมธอด `flatten().fieldErrors` จาก Zod ให้ผลลัพธ์เป็นอ็อบเจกต์ที่มีโครงสร้างสมบูรณ์แบบซึ่งจับคู่ชื่อฟิลด์กับอาร์เรย์ของข้อความแสดงข้อผิดพลาด ซึ่งเป็นสิ่งที่คอมโพเนนต์ฟอร์มของเราต้องการพอดี

แนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยที่สำคัญสำหรับ Server Actions

การใช้ไลบรารีการตรวจสอบความถูกต้องเป็นก้าวที่ยิ่งใหญ่ แต่ความปลอดภัยที่แท้จริงต้องการแนวทางแบบหลายชั้น ทุก Server Action คือช่องทางการโจมตีที่อาจเกิดขึ้นได้

1. สันนิษฐานเสมอว่ามีเจตนาร้าย

อย่าเชื่ออินพุตของผู้ใช้เด็ดขาด นี่คือกฎทอง แม้ว่าโค้ดฝั่งไคลเอนต์ของคุณจะส่งข้อมูลที่สมบูรณ์แบบ ผู้โจมตีก็สามารถใช้เครื่องมืออย่าง `curl` หรือ Postman เพื่อส่งคำขอที่สร้างขึ้นเองโดยตรงไปยัง endpoint ของ Server Action ของคุณได้ ตรรกะฝั่งเซิร์ฟเวอร์ของคุณคือการป้องกันที่น่าเชื่อถือเพียงอย่างเดียว

• ตรวจสอบทุกอย่าง: ไม่ใช่แค่รูปแบบ แต่รวมถึงตรรกะทางธุรกิจด้วย ผู้ใช้นี้ได้รับอนุญาตให้สร้างใบแจ้งหนี้สำหรับลูกค้าราย *นี้* หรือไม่? จำนวนเงินอยู่ในช่วงที่สมเหตุสมผลหรือไม่?
• กรองข้อมูลสำหรับ Output: ในขณะที่ React จะทำการ escape ข้อมูลโดยอัตโนมัติเพื่อป้องกัน XSS เมื่อแสดงผล หากคุณใช้ข้อมูลในบริบทอื่น (เช่น การสร้างอีเมล, การบันทึก log) ให้ระมัดระวังในการกรองข้อมูล (sanitizing) เพื่อป้องกันการแทรกสคริปต์ในระบบเหล่านั้น

2. การพิสูจน์ตัวตนและการให้สิทธิ์เป็นสิ่งจำเป็น

ทุก Server Action ที่ทำการเปลี่ยนแปลงข้อมูล (สร้าง, อัปเดต, ลบ) หรือเข้าถึงข้อมูลที่ได้รับการป้องกันจะต้องตรวจสอบตัวตนและสิทธิ์ของผู้ใช้

เริ่มต้น action ของคุณด้วยการตรวจสอบ session เสมอ:

            // app/actions.js
'use server';

import { auth } from '@/auth'; // Assuming you use NextAuth.js or similar
import { sql } from '@vercel/postgres';

export async function deleteInvoice(id) {
  const session = await auth();
  if (!session?.user) {
    // Or throw an error
    return { message: 'Authentication required.' };
  }

  // Authorization check: Does this user have permission to delete?
  // This could involve checking roles or ownership.
  const userRole = session.user.role;
  if (userRole !== 'admin') {
    return { message: 'Unauthorized action.' };
  }

  try {
    await sql`DELETE FROM invoices WHERE id = ${id}`;
    revalidatePath('/dashboard/invoices');
    return { message: 'Deleted Invoice.' };
  } catch (error) {
    return { message: 'Database Error: Failed to Delete Invoice.' };
  }
}
            

              
                Copy
              
            
          

3. การป้องกัน CSRF (Cross-Site Request Forgery)

การโจมตีแบบ CSRF หลอกลวงให้ผู้ใช้ที่ล็อกอินอยู่ส่งคำขอที่เป็นอันตรายไปยังแอปพลิเคชันของคุณโดยไม่รู้ตัว โชคดีที่เฟรมเวิร์กอย่าง Next.js มีการป้องกัน CSRF ในตัวสำหรับ Server Actions โดยใช้เทคนิคผสมผสานกัน รวมถึง double-submit cookies และการตรวจสอบ origin แม้ว่าสิ่งนี้จะถูกจัดการให้คุณแล้ว แต่ก็เป็นสิ่งสำคัญที่ต้องตระหนักและแน่ใจว่าคุณไม่ได้สร้างช่องโหว่โดยไม่ได้ตั้งใจจากการกำหนดค่าที่ผิดพลาด

4. ใช้การจำกัดอัตรา (Rate Limiting)

ผู้ใช้หรือบอทที่เป็นอันตรายอาจสแปมการส่งฟอร์มของคุณ, พยายาม brute-force การล็อกอิน, ทำให้การเชื่อมต่อฐานข้อมูลของคุณหมดลง, หรือเติมข้อมูลขยะลงในระบบของคุณ การใช้การจำกัดอัตรากับ Server Actions ที่สำคัญจึงเป็นสิ่งจำเป็น

คุณสามารถใช้บริการอย่าง Upstash Rate Limiting หรือใช้ตรรกะของคุณเองโดยใช้ key-value store อย่าง Redis โดยคีย์มักจะเป็นที่อยู่ IP หรือ ID ของผู้ใช้

            import { Ratelimit } from '@upstash/ratelimit';
import { Redis } from '@upstash/redis';

// Create a new ratelimiter, allowing 5 requests per 10 seconds
const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(5, '10 s'),
});

export async function sensitiveAction(formData) {
  const ip = headers().get('x-forwarded-for'); // Or get user ID from session
  const { success } = await ratelimit.limit(ip);

  if (!success) {
    return { message: 'Too many requests. Please try again later.' };
  }

  // ... rest of the action logic
}
            

              
                Copy
              
            
          

ข้อควรพิจารณาด้าน Global และการเข้าถึง (Accessibility)

การสร้างแอปพลิเคชันสำหรับผู้ใช้ทั่วโลกต้องคำนึงถึงมากกว่าแค่การใช้งานทางเทคนิค

การทำให้เป็นสากล (i18n) ของข้อความแสดงข้อผิดพลาด

การเขียนข้อความแสดงข้อผิดพลาดเป็นภาษาอังกฤษแบบตายตัว (hardcoding) ไม่เหมาะสำหรับแอปพลิเคชันระดับโลก แนวทางที่ดีกว่าคือให้ Server Action ของคุณคืนค่าเป็น *โค้ด* หรือ *คีย์* ของข้อผิดพลาด

            // In the action
if (!validatedFields.success) {
  // ...
  return { errors: { customerId: ['error.customer.required'] } };
}

// In the client component, using a library like 'react-i18next'
import { useTranslation } from 'react-i18next';

function MyForm() {
  const { t } = useTranslation();
  const [state, dispatch] = useFormState(...);

  // ...
  {state.errors?.customerId && 
    
{t(state.errors.customerId[0])}
}
}
            

              
                Copy
              
            
          

สิ่งนี้จะแยกตรรกะการตรวจสอบของคุณออกจากส่วนการนำเสนอ และช่วยให้ front-end ของคุณจัดการการแปลภาษาได้อย่างราบรื่น

การเข้าถึง (a11y)

เมื่อแสดงข้อผิดพลาด ตรวจสอบให้แน่ใจว่าผู้ใช้เทคโนโลยีช่วยเหลือสามารถเข้าถึงได้ เชื่อมโยงข้อความแสดงข้อผิดพลาดกับฟิลด์อินพุตที่เกี่ยวข้องโดยใช้แอตทริบิวต์ `aria-describedby`

            

  Customer Name
  
  

    {state.errors?.customerName &&
      state.errors.customerName.map((error) => (
        
{error}
      ))}
  

            

              
                Copy
              
            
          

แอตทริบิวต์ `aria-live="polite"` จะช่วยให้โปรแกรมอ่านหน้าจอ (screen reader) ประกาศข้อความแสดงข้อผิดพลาดเมื่อมันปรากฏขึ้น

สรุป: ยุคใหม่แห่งความรับผิดชอบ

React Server Actions เป็นเครื่องมือที่ทรงพลังที่ช่วยให้การพัฒนา full-stack มีความคล่องตัวมากขึ้น ทำให้ตรรกะของเซิร์ฟเวอร์ใกล้ชิดกับ UI มากกว่าที่เคยเป็นมา อย่างไรก็ตาม พลังนี้ต้องการกรอบความคิดที่เน้นความมีวินัยและความปลอดภัยเป็นอันดับแรก

ด้วยการใช้ hook อย่าง `useFormState` และ `useFormStatus` เราสามารถสร้างฟอร์มที่ปรับปรุงแบบก้าวหน้าพร้อมประสบการณ์ผู้ใช้ที่ยอดเยี่ยม ด้วยการผสานรวมไลบรารีการตรวจสอบสคีมาที่แข็งแกร่งอย่าง Zod เราสามารถเขียนตรรกะการตรวจสอบที่สะอาด, ดูแลรักษาง่าย, และปลอดภัยด้านประเภทข้อมูล และด้วยการยึดมั่นในหลักการความปลอดภัยพื้นฐาน—การพิสูจน์ตัวตน, การให้สิทธิ์, การจำกัดอัตรา, และการตรวจสอบบนเซิร์ฟเวอร์เสมอ—เราสามารถสร้างแอปพลิเคชันที่ไม่เพียงแต่สวยงามและมีประสิทธิภาพ แต่ยังยืดหยุ่นและปลอดภัยอีกด้วย

ปฏิบัติต่อทุก Server Action เหมือนเป็น API endpoint สาธารณะ ตรวจสอบอินพุตของมัน, ตรวจสอบสิทธิ์ของมัน, และจัดการข้อผิดพลาดของมันอย่างเหมาะสม ด้วยการทำเช่นนี้ คุณจะสามารถใช้ประโยชน์จากศักยภาพสูงสุดของบทใหม่ที่น่าตื่นเต้นนี้ในการพัฒนา React ได้อย่างมั่นใจ